Various classes of block diagrams may describe computations that can be performed on application specific computational hardware, such as a computer, microcontroller, Field Programmable Gate Array (FPGA), and custom hardware. Classes of such block diagrams may include time-based block diagrams, such as those implemented within the well-known Simulink® software product available commercially from The MathWorks, Inc., Natick, Mass., state-based and flow diagrams, such as those found within the Stateflow® software product available from The MathWorks, Inc. and data-flow diagrams. A common characteristic among these various forms of block diagrams is that they may be used to define semantics on how to execute the diagram.
Historically, engineers and scientists have utilized time-based block diagram models in numerous scientific areas, such as feedback control theory and signal processing to study, design, debug, and refine dynamic systems. Dynamic systems, which may be systems where behaviors change over time, may be representative of many real-world systems. Time-based block diagram modeling has become particularly popular with the advent of software products such as the Simulink® software product. Such products may provide sophisticated software platforms with a rich suite of support tools that may make the analysis and design of dynamic systems efficient, methodical, and cost-effective.
Graphical modeling environments, such as those provided by the Simulink® software product may assist in simplifying the process of designing, simulating, and implementing dynamic systems. Tools provided in such software environments may generally permit, e.g., a user to create a graphical representation of a system, such as block diagram representations, statistical diagrams, timing diagrams, and other similar graphical elements that can be used to describe system behavior.
Block diagrams generally include graphical entities having an “executable meaning” that are created within time-based block diagrams for modeling a dynamic system, and generally comprise one or more graphical objects. For example, a block diagram model of a dynamic system may be represented schematically as a first collection of elements including one or more graphical objects, such as nodes, which may be interconnected by another set of graphical objects, generally illustrated as lines, which may represent logical connections between the first collection of graphical objects. In most block diagramming paradigms, the nodes are often referred to as blocks and drawn using some form of geometric object (e.g., circle, rectangle, etc.). The nodes themselves may be blocks that correspond to other subsystems having their own block diagrams.
Line segments connecting graphical objects (or provided as inputs or outputs of graphical objects) are often referred to as signals. Signals may correspond to time-varying quantities represented by one or more line connections and may be assumed to have values at each time instant. A node may represent an elemental dynamic system, and relationships between signals and state variables may be defined by sets of equations represented by the nodes. Inherent in the definition of signals is the notion of parameters, which may be coefficients of equations. Such equations may generally define a relationship between input signals, output signals, state, and time, so that one or more lines may represent the input and/or output of an associated elemental dynamic system. A line emanating at one node and terminating at another may signify that the output of the first node is provided as an input to the second node. A distinct input or output on a node may be generally referred to as a port. A source node of a signal may generate the signal and write the signal to an output port at a given time instant when its system equations are solved. A destination node that receives this signal may read this signal when their system equations are being solved. Here, the term “nodes” may not refer exclusively to elemental dynamic systems but may also include other modeling elements that aid in readability and modularity of block diagrams.
For example, in the Simulink® software product, an example of a time-based block diagram environment may include a model of a dynamic system defined as a block diagram comprising a number of graphical objects. As discussed, a block diagram may comprise a plurality of nodes, called blocks, which may be interconnected by lines that represent signals. A block may represent a functional entity, such as an elementary dynamic system, which may implement a mathematical operation, e.g., an algorithm or equation, on the data being processed by the system represented by the block diagram. A block may produce an output either continuously (a continuous block) or at specific points in time (a discrete block). The type of the block often determines a relationship between a blocks outputs and its inputs, states, and time. A block diagram can contain any number of instances of any type of block needed to model a system. The signals in a block diagram model may represent a time-varying quantity that may be updated, e.g., read-by and written-to, by the blocks. Software products used to model dynamic systems may provide a graphical user interface (GUI) for building models of dynamic systems as block diagrams. A block diagram may be built by dragging and dropping blocks provided in pre-defined blocksets or custom developed by, e.g., a user.
Other examples of block diagrams may include state chart diagrams, such as those found within the well-known Stateflow® software product, also available from The MathWorks, Inc., data flow diagrams, and so on. Many graphical modeling systems employing block diagrams are hierarchical. A hierarchical diagram often consists of ‘layers’ where a layer may be a diagram in and of itself and may be represented in a ‘parent’ layer as a single block. Connections to the block may be routed into a lower layer. This lower layer may also include blocks, along with other blocks that refer to other block diagrams which may be lower in the hierarchy.